Mobile IP has a functionality for maintaining an association between a home address of a mobile node and its current topologically correct care of address from a visited network. For example, in mobile IPv6 protocol this functionality is called home agent which maintains the association, also known as a binding, between the home address of the mobile node and its current topologically correct care of address from the visited network. This functionality is described by D. Johnson, C. Perkins, J. Arkko in “Mobility Support in IPv6”, Internet Draft version 18, Internet Engineering Task Force, Jun. 1, 2002, which document is referred to as reference (1) hereafter.
The home agent resides typically in the home network from where the mobile node has configured its “static” home address that is advertised through the DNS (Domain Name Server) system and that provides global reachability for correspondent nodes. Reference (1) mandates for the primary care of address registration a sequence of verifications to be performed for a binding update message before the registration can be accepted. According to mobile IPv4 protocol, the binding update message is a registration message.
In reference (1) it is described that the home agent verifies the binding update message, i.e. it checks whether it is a first home agent and whether the home address of the mobile node in the binding update message is an on-link address. Moreover, if the home agent chooses to reject the requested binding update for any other reason, e.g. due to insufficient resources to serve another mobile node as a home agent, then the home agent should return a binding acknowledgment message to the mobile node, in which a status field is set to an appropriate value to indicate the reason for the rejection.
There are several possible scenarios for the deployment of mobile IP in terms of how a mobile node (MN) can identify and locate a home agent (HA) in its home network:                MN performs dynamic HA discovery, i.e. it sends a request to an anycast address in the home network, and more precisely on the home link, and receives a response from an HA willing and capable to serve the MN;        MN is pre-configured, e.g. at subscription time, with the address of one or more HAs that can serve the MN, and the MN will use them according to a priority scheduling determined by a service provider (e.g. use always the first in the list and switch to the second one when the first one is not available, use a round-robin algorithm to select between them, etc.).        
In the first scenario, two round trip messages are needed between the MN and the home network to register the MN with the HA and therefore make the MN reachable at the IP level. In general, this procedure can work but the signaling load required may be unacceptable in several situations, e.g. access over a wireless link. Also, the delay involved in this procedure can be significant if the point of attachment of the MN is geographically far from the home network. Moreover, the HA discovery procedure is not secure.
In several deployments, the second scenario (i.e. HA addresses pre-configured in the MN) is more feasible. For example, a similar scenario is already adopted in other frameworks, e.g. to support VPN (Virtual Private Network) the addresses of the VPN gateways are pre-configured in the VPN client.
In this second scenario, the MN sends a binding update message to a primary HA in the list, i.e. the one that should be tried first. In case the HA is not able to serve the MN due to resources limitations, or due to configuration changes in the home network, e.g. the HA address is not valid anymore, as described above, the MN is provided with a reject information. At this point, the MN needs to try with another HA from its home agent list or try to discover a new one with the dynamic home agent discovery mechanism.
If the MN uses its local copy of the Home Agent list, it is likely that this list is stale because the information on the primary HA was also outdated, consequently the same is likely to apply with the other entries. In particular, if the home agents at the home network are using dynamic load balancing based on the advertised preferences there is a considerable possibility that the home agent list at the mobile node is not up to date with the load balancing status of the home network. In addition, even if the list is not outdated, this requires the MN to send a new binding update.
Alternatively, when receiving the reject information, the MN can perform the dynamic home agent discovery. However, this requires a second binding update and round trip of messages between the MN and the HA and introduces an additional delay and extra messaging that might in some cases be harmful. This can happen for example when a home agent at a previous visited link is used for forwarding packets to a new home agent/router at a new link.
According to the prior art, the above-mentioned problem has been solved in that the MN has to perform a dynamic home agent discovery procedure first, and then send a binding update to the HA discovered. However, this requires two round trips between the MN and the HA and can introduce delay.
Alternatively, according to the prior art, when the HA rejects the first binding update which has been sent to the HA according to a pre-configured list in the MN, for example, the MN is forced to perform a dynamic home agent discovery procedure and then send another BU. However, this requires three round trips between the MN and the HA and can introduce even more delay.